Expands the existing 5.0.0 stub (which previously covered only the CRAM
3.1 write work) into a complete entry covering everything since 4.3.0.

Adds:

- Lead headlines summarizing the major themes (CRAM 3.1 writing, slimmer
  runtime deps, faster BAM [de]compression, enforced formatting, fixed
  test reporting).
- A prominent ⚠️ Breaking changes section calling out SRA removal,
  Nashorn now opt-in, the SAMRecord.toString() format change, the
  removed CRAM slice digest tags, and the new default CRAM version 3.1.
- A new "CRAM correctness and cross-implementation fixes" section
  consolidating the read- and write-path fixes that improve interop
  with samtools/htslib (TLEN computation, CIGAR =/X comparison, CIGAR
  reconstruction for sequence '*', container-with-no-slices crash,
  archive header overflow, unmapped-read query, supplementary/secondary
  read-name limitation).
- Performance entries beyond just the CRAM-internal optimizations:
  jlibdeflate integration, the BAM decoding path improvements, and a
  long-read-friendly bases-per-slice threshold.
- A bug-fix section covering the LTF8 9-byte write fix, the
  SamLocusIterator offset bug, the SamPairUtil dovetail fix, and the
  snappy native-load UnsatisfiedLinkError catch.
- A build, tooling, and dependency clean-up section: Palantir Java
  Format + Spotless enforcement, Maven Central portal migration,
  snapshot version naming, deprecation cleanup, the test-runner
  pass/fail-reporting fix, and the dependency clean-up (commons-logging
  constraint, Nashorn compileOnly, ngs-java removal).
- A compatibility line noting JDK 17 / 21 / 24 spot-checks.
- Expanded testing entries: the hts-specs CRAM 3.0/3.1 compliance
  tests, FQZComp round-trip tests, CRAI correctness tests, test-suite
  speedups, the CEUTrio test-data downsizing, and the JS filter test
  bulk-up.

Source for the additions was the full git log since the 4.3.0 tag plus
the unsquashed backup branch tf_cram_31_backup_20260425, which retains
fine-grained commits that the merged CRAM 3.1 PR squashed away.

The CRAM write-speed gains are intentionally not headlined yet --
prior htsjdk wrote CRAM 3.0 (lower compression, fewer codec passes), so
"faster" without "and same/better compression" would be misleading.
We'll revisit the perf bullet after benchmarking against samtools.